Out of curiosity — may I ask what concrete use case you’re trying to support with this?

I’ve been exploring this area myself, and I might be misunderstanding something, but from what I can tell, the MCP server maintains a fairly static registry. Either through attribute discovery or manual registration. The container seems focused on injecting dependencies into tool handlers, not on dynamically filtering or scoping tools — which makes sense, given how shallow PSR-11 is.

So if this PR is about enabling more dynamic resolution, I’m wondering whether this kind of logic really belongs at the attribute level or whether we might eventually need a more expressive registry or tool resolution layer instead?

If the goal is extensibility via attributes, I’d lean toward defining interfaces rather than relying on inheritance. That might offer a cleaner extension point while keeping the existing classes final and predictable.

Hey, thanks for putting this up.

I get the motivation for wanting to extend the MCP attribute classes, but I’m not really seeing a practical use case for it in the context of how the MCP server works right now. The core attributes like McpTool, McpResource, McpPrompt, and McpResourceTemplate are really just a way for the Discoverer to pick up the standard MCP elements. The properties they expose (name, description, mimeType, etc.) are all pretty much dictated by the MCP spec and are meant to be consistent across the board.

If you want to add extra metadata or annotations for your own app’s needs (like say, custom scopes or tags), it’s actually cleaner to define your own attribute for that and then use reflection in your own code to read and act on those. The Discoverer isn’t going to know or care about those extra properties anyway, since it’s only looking for the standard MCP stuff. It doesn’t even have any hooks or extension points for custom properties 🤷🏽‍♂️

If the MCP spec ever adds new fields or requirements, we can always update the core attributes and the Discoverer to support those. But for app-specific stuff, custom attributes and your own reflection logic are the way to go.

So, I’m leaning toward keeping these classes final for now, just to keep things predictable and in line with the spec. If there’s a really compelling use case for subclassing that I’m missing, I’m open to hearing it!